Power Tools 1993 November - Disc 2/Power Tools Plus (Disc 2 of 2)(November 1993)(HP).iso/hotlines/gsyhl/dstsecwp/dstsecwp.txt

Text File | 1993-07-06 | 58KB | 1,055 lines

               Secure Open Computing
               Strategy For
               Global Enterprises


               A White Paper


               March, 1993

               General Systems Division


Table of Contents

1  Introduction
1.1  Hewlett Packard Commitment to Security
1.2  Purpose and Scope
1.3  Strategy Development Process
2  HP Information Security Vision
3  HP Information Security Value Proposition
4  HP Information Security Strategy and Development Model
4.1  Strategy Principles
4.2  HP Distributed Computing Environment (DCE) Security Strategy
4.2.1  Distributed Computing Environment (DCE) Overview
4.2.2  DCE Security Evolution
4.2.3  Longer-Term DCE Security Evolution
4.2.4  Security Aspects Not Addressed by DCE
4.2.5  Role of Local System Support within DCE Domains
4.2.6  DCE Security Policy Directions
4.3  DCE-Independent Methods to Enhance Computing Environment Security
4.3.1  Enhanced Security Operating System Mechanisms
4.3.2  Application Support Services
4.3.3  System Management Facilities
4.3.4  Networking Elements
4.3.5  Trusted Hardware Components
4.3.6  Alternative APIs for Security Services
4.3.7 Alternative Security Architecture Standards
4.4  Network Planning
5.  Application of HP's Security Strategy:  Case Example

1  Introduction

1.1  Hewlett Packard Commitment to Security

Hewlett-Packard continues to establish itself as a strategic information
technology supplier to industry leading enterprises worldwide.
Increasingly, these large global accounts are adopting open systems on a
global scale and new paradigms of computing such as client-server. These
trends complicate the job of securing an organization's information
assets from unauthorized access.

On the leading edge of these trends are information-intensive market
sectors such as financial services and telecommunications.  Typically,
organizations in these sectors require a security strategy that supports
both the distributed cooperative application model of the future as well
as the traditional monolithic application model prevalent today.

HP is committed to delivering security solutions that address the
complex security challenges associated with the need to evolve to future
distributed computing environments.

1.2  Purpose and Scope

The objectives of this document are two-fold.  First, this document
describes Hewlett-Packard's information security vision and development
model for global, distributed, computing environments.  HP calls this
vision and model Secure Open Computing.  Critical technology components
of HP's model are identified and HP's position relative to technology
alternatives are articulated.  Second, this document establishes a
framework by which customers can compare and contrast HP's vision,
strategy, and technology assessments with that of their own.

1.3  Strategy Development Process

HP's strategy development process began with the formation of a System
Security Council to coordinate the development and implementation of the
Secure Open Computing strategy company-wide.  This team consists of
marketeers and technologists representing multiple divisions across the
company.

HP's strategy is shaped by a number of inputs.  HP is partnering with
early adopters of security technology to gain a detailed understanding
of customer needs and experience with implementing leading-edge security
technologies.  HP's strategy anticipates and integrates technology
advances spawned from both internal research and industry innovation.
Finally, HP closely monitors competitor and standardization activities
to ensure market acceptance of its solutions.

While HP's security vision will remain stable, its strategy for
implementation may adjust in response to the pace of technological
advances, standardization processes, or changes in customer needs.  HP
invites its leading accounts to comment on the strategy articulated in
this document to ensure that it reflects their evolving needs.

2    HP Information Security Vision

The goal of any product strategy is to progress a program towards a
clear and stable vision.  Thus, before elucidating on strategy, it is
necessary to describe HP's vision of Secure Open Computing.  In general,
HP envisions computing solutions with security services that can be
characterized as Comprehensive, Configurable, and Usable.  At the same
time, HP envisions a security architecture that is consistent with
investment protection and business and information technology (IT)
Strategic objectives.

COMPREHENSIVE SECURITY

The goal of HP's security solution is to offer a comprehensive set of
security services that ensure the availability, integrity and
confidentiality of an organization's global information assets.  These
information assets can span both legacy and distributed application
resources, PC to mainframe class systems, as well as to customer and
supplier system interfaces.  Comprehensive security includes the concept
of end-to-end (ETE) security of network message and transaction traffic.
ETE security must be implemented such that there is minimal change in
the network infrastructure and assurance that the introduction of a
single, inherently non-secure component can not compromise the security
of the whole network.

Finally, comprehensive security encompasses not only system and software
functionality and tools but training, consulting and support, disaster
recovery services, and meaningful documentation.  HP anticipates the
need to integrate in-house development with security solutions from
third-parties so that customers have a degree of choice and access to
best-in-class solutions.  Similarly, HP will work with other systems
vendors to ensure interoperability and interface consistency where
possible.

CONFIGURABLE SECURITY

Security building blocks must be modular and flexible to allow entities
to tailor their security implementation to meet the requirements of
their particular organization's security policy.  All available security
services (i.e., authentication, authorization, confidentiality,
integrity, non-repudiation, audit) need the ability to be implemented
independently or in any combination.

USABLE SECURITY

Unintentional user mistakes are responsible for as much as 90% of all
security breaches.  Most mistakes are caused by the complexity of
security facilities and user-interfaces that users with no security and
operating system expertise are expected to utilize. Therefore, within
the constraints of an individual organization's security policy,
security must be unobtrusive to the end-user and should enhance rather
than degrade the productivity of end-users whenever possible. For
example, smart cards will support a single sign-on capability for
end-users to access all authorized resources of the network from
anywhere on the network.

Administrators require logically centralized management of security
services that are consistent and integrated with a common system and
network management framework.  Developers require programming aids and
tools for construction, test, and maintenance of secure applications.

STRATEGIC SECURITY

Organizations will evolve their computing infrastructure to more
distributed or cooperative paradigms to achieve lower cost of
operations, increased productivity and efficiency, or competitive
advantage.  HP's security must be complementary and not incongruous with
these objectives.  For example, with respect to competitive advantage,
HP envisions a security perimeter that can be extended to include both
customer and supplier system interfaces, thus removing the security
obstacles inherent in entering or developing new markets such as home
banking, EDI, enhanced telecommunications services, multi-media, and
portable/mobile computing services.

A model for visualizing several key elements of HP's Secure Open
Computing vision is offered above.  HP refers internally to this
high-level model by the code name UT.  The 'U' represents the secure
end-to-end communication between users or processes over a global
network.  The 'T' represents the comprehensive family of security
services which are administered by consistent network management
interface.  This graphic also introduces and defines some fundamental
security terminology used throughout this document.

3    HP Information Security Value Proposition

As HP pursues its vision of Secure Open Computing, HP will sustain four
important advantages relative to its competition.  First, HP will
maintain industry leadership in driving and implementing international
security standards.  In general, HP is among the first to be compliant
with new standards and HP technologies are routinely selected as
industry standards.  HP has over 300 employees participating in
standards committees.

Second, HP will provide integrated security solutions across the
broadest range of scalable business servers and devices.  The HP9000
family of workstations and business servers based on the HP Precision
Architecture (RISC) -- widely regarded in the industry as the broadest
scalable family of computing systems -- is suitable for everything from
individuals to small work groups to large data center configurations.

Third, HP will provide excellent pre- and post-sales security
consulting, training and support.  HP views consulting and support
competency to be a critical success factor in its security solution.
Over the past nine years of U.S. Datapro surveys, HP has consistently
ranked the highest in support and service.  Additional independent
research rates HP as a worldwide leader in overall customer support
satisfaction, as well as customer satisfaction.

Finally, HP offers early access to cutting-edge business re-engineering
building blocks including distributed security technology.  HP is a
primary architect and technology contributor to the Open Software
Foundation's Distributed Computing Environment (DCE) and Distributed
Management Environment (DME).  HP also has significant experience in
delivering multi-level secure system and network solutions to the most
complex security environments within federal defense and intelligence
communities worldwide.

4    HP Information Security Strategy and Development Model

This section describes HP's Secure Open Computing strategy for global
enterprises.  It presents HP's strategy in the context of the model
shown below.

The figure illustrates a distributed security model which consists of
four conceptual layers in which security can be implemented.

  1. Distributed applications and applications which implement security
     policies
  2. Distributed security middleware
  3. Operating system security
  4. System & network hardware security

There are two general schemes to structure and implement security
services and technology.  One scheme is represented by the DCE framework
as depicted on the right hand side of the figure.  HP has chosen to
adopt DCE as its strategic distributed computing and distributed
security framework.  HP believes that DCE provides the most
comprehensive and flexible approach to providing security in a
distributed environment.  This choice, however does not imply the
abandonment of or incompatibility with other security environments.
However, HP does target DCE and DCE security solutions at customers
which are willing to re-engineer parts of their IT business and make the
paradigm shift to true client-server computing.  As shown in the figure,
the DCE security framework provides the distributed security middleware
as well as some elements traditionally the domain of application policy
and operating system security.

The other scheme shown on the left essentially represents a piece by
piece approach to addressing specific security threats.  It consists of
multiple, layered, overlapping solutions which can provide different
aspects of security.  For example, Kerberos provides a distributed
framework for authentication with a fixed policy but no operating system
security elements while RACF provides security at the operating system
level with little regard for distributed environments. Similarly,
hardware-based encryption devices increase security only at the network
communications level.  This approach is viable mainly in computing
environments in which a few primary threats have been identified and the
preservation of legacy systems and applications is a primary goal in
addressing these threats.

HP's leading edge customers are investing in both approaches.  As a
result, HP's strategy must address both schemes.  Section 4.1 states the
principals or philosophical pillars upon which HP's strategy for
addressing either scheme rests.  As a technology provider, HP provides
the DCE distributed security framework which is the central technology
framework of HP's strategy.  This framework is described in Section 4.2.
As a vendor of robust, secure systems and networks, HP provides a
variety of operating system security, network security, and add-on
security products which complement DCE or are of value in non-DCE
environments.  These features are described in Section 4.3.  Finally,
Section 4.4 details network planning issues which are relevant to all
security conscious customers.

4.1  Strategy Principles

HP's secure open computing strategy is based on three key principles or
success factors.  First, HP will leverage -- and not trade-off -- its
traditional strengths in the areas of interoperability, usability,
performance, and service & support.

Second, HP is committed to providing application investment protection
when migrating to enhanced security environments.  For forward migration
of new applications HP's intention is to adopt industry standard APIs.
For co-existence of legacy applications with future distributed
applications, HP's goal is to provide migration tools and/or application
access transparency.

Third, HP is committed to pro-actively submitting and implementing
industry and international computing standards including information
security-specific standards.  To facilitate multi-vendor secure
interoperability HP will work cooperatively with competitors by, for
example, hosting interoperability forums or engaging in joint
development activities.

4.2  HP Distributed Computing Environment (DCE) Security Strategy

HP has identified DCE as a critical strategic framework for delivering
future open distributed computing solutions.  HP believes that DCE will
set a de facto standard for secure distributed computing in a
multi-vendor environment.  As a result, HP is committed to providing DCE
on both the HP-UX and MPE/ix operating system platforms.

HP's strategy to provide Secure Open Computing is multi-faceted.  First,
HP will continue to be a leader in implementing and evolving the basic
DCE security features described in the next section.  The following
sections 4.2.2 and 4.2.3 describe the near-term and longer-term strategy
for enhancing DCE to provide increased service levels, extensibility to
future and legacy systems, and additional facilities such as DCE
auditing.  Section 4.2.4 exposes HP's position on security services
which currently remain outside the definition of DCE such as
non-repudiation facilities.  HP will invest in local system capabilities
identified in section 4.2.5 which complement the level of security
service provided by DCE such as encryption/integrity hardware for
performance and smart card support for safe key distribution/storage and
two-factor authentication.  Section 4.2.6 describes future directions
for integrating additional security policies into DCE.  Finally, Section
4.3.7 describes a  security architecture alternative to DCE.

4.2.1  Distributed Computing Environment (DCE) Overview

The DCE security component is a set of services and facilities that
provide distributed applications with a trustworthy mechanism for
controlling access to application resources.  The fundamental pieces of
the security component are (1) a logically centralized registry of user
information and privileges; (2) a common authorization model across
disparate applications; (3) integral facilities for inter-domain
administration and connectivity; (4) integral facilities for
communication integrity and confidentiality; and (5) a hierarchical
design of security services that provide high availability and
robustness in the presence of partial system failures.

The DCE user registry is an extension of the distributed name system
that specializes in storing user security information.  The logon
sub-system of DCE accesses the repository and provides users with a
single identity across all systems.  Authentication of the user's
identity is performed using the Kerberos Version 5 authentication
protocol.

Access to services in the DCE is controlled through the use of access
control lists (ACLs).  DCE ACLs are a superset of the draft POSIX ACL
specification -- extending the basic functionality with provisions for
multiple administrative domains and for use by services other than
conventional file systems.  This facility provides a common model for
authorization across all basic DCE services as well as end-user
developed applications.

The protection of resources (e.g., files, database objects, etc.)  via
ACLs is only meaningful when the application exporting the resource can
reliably determine the identity of the caller.  The DCE remote procedure
call (RPC) facility is integrally connected with the security component
to provide mutual client/server authentication of identity. Applications
can additionally request that data transmitted via the RPC be protected
with either secure integrity or confidentiality protocols.

Security is an essential service of the DCE and is therefore implemented
in a robust, highly available manner.  In a distributed environment,
robustness is not simply a matter of careful coding.  Partial failures
due to network outages or scheduled maintenance are a part of normal
operations.  A robust distributed service is one that continues to
operate, possibly with some limitations, in the presence of these
failures.  DCE uses a hierarchical and redundant approach to providing
security services.  The logically centralized security service is
replicated so that network partitions do not prevent applications from
obtaining necessary security information.  Client machines retain enough
data from the network service to allow them to provide local services to
users in the event that the network is completely unavailable.

4.2.2  DCE Security Evolution

The evolution of DCE falls into two broad categories.  In the short term
DCE is maturing though the completion and improvement of features
present in the base design.  In the longer term additional features are
added to the environment to extend its suitability to broader
application domains.  HP's strategy calls for key efforts in both areas
and HP is collaborating with others to define long-term extensions for
DCE.

Replication of the user registry database is the primary short term
enhancement to the DCE security service.  This facility is crucial to
the creation of large distributed environments -- protecting the
environment from the vagaries of partial failures.

4.2.3  Longer-Term DCE Security Evolution

The OSF has solicited proposals in the form of requests for comments
(RFCs) to help define the future of DCE.  This process has been very
successful, and has resulted in a number of contributions to the OSF by
HP and others in the DCE community.  HP's contributions are in the areas
of Extensibility to Legacy Systems, Delegation, Inter-domain Access, and
Stronger Authentication.  Other vendor proposals are in the areas of
Non-RPC Application Integration, Auditing, and Public Key Support.
These directions are described next as well as HP's Security Management
direction for DCE (as well as Non-DCE) environments.

EXTENSIBILITY TO LEGACY SYSTEMS

Extensibility of the data associated with a user or server identity is a
key concern for both supporting legacy systems and for adding additional
authorization models.  HP has submitted DCE-RFC 6 defining a facility
for maintaining and verifying arbitrary attributes, such as application
or local operating system specific authorization data (e.g., legacy UIDs
and passwords), in the DCE Account Registry.  This extension will also
make possible the implementation of a single logon facility that
embraces legacy applications and non-UNIX derived operating systems.

DELEGATION

The base DCE environment provides mechanisms for clients and servers to
perform mutual authentication.  In complex environments, however,
servers will frequently need to access the services of other servers to
perform the request of the client.  Delegation or proxy provides a
mechanism for chaining services requests securely.  HP's DCE-RFC 3
provides a model for chaining identities and enhancements to the
authorization model to reflect chained identities.

INTER-DOMAIN ACCESS

Hierarchical designs provide robustness in the implementation of the
security server.  This strategy can also be used to reduce the
management burden of access across administrative domains. HP's DCE-RFC
7 defines the trust relationships between administrative domains when
those domains form a hierarchy in the DCE global name space.

STRONGER AUTHENTICATION

Stronger authentication protocols protect users from password guessing
attacks.  HP's DCE-RFC 26 elaborates existing Kerberos protocol features
to protect users from network password guessing attacks.  These protocol
enhancements are coupled with changes to the user registration service
so that password guessing attacks can be detected and so that the
security system can take corrective action as attacks occur.

NON-RPC APPLICATION INTEGRATION

Extensions to the DCE security environment have also been proposed by
other suppliers.  DEC has proposed to broaden the applicability of the
DCE security environment to non-RPC applications through the use of the
GSSAPI -- a general interface to distributes security services.  GSSAPI
provides an API for performing mutual authentication and the integrity
and confidentiality protection of data without pre-supposing a
communication strategy.  This addition makes it easier to integrate
existing applications that use existing network and communication
facilities into DCE by not requiring the application re-engineering with
RPC.  DEC has further provided DCE-RFC 5 which defines extensions to the
GSSAPI to make it work with DCE's authorization data, privilege
attribute certificates (PACs).  This extension strengthens the appeal of
GSSAPI by allowing non-RPC distributed applications to also participate
in the DCE authorization model.

AUDITING

Accountability is essential in many environments.  The OSF is
considering two competing proposals for the addition of auditing
facilities to DCE.  The OSF itself has proposed adding an auditing
facility in DCE-RFC 25 that would initially audit events in the base
security relevant DCE components.  IBM has submitted a broader proposal
in DCE-RFC 28 and 29 to provide a more general facility appropriate for
use in customer applications.  The likely adoption of either model will
strengthen the DCE and provide a convenient mechanism for key DCE
services to integrate with local system auditing facilities in addition
to the DCE-wide auditing foreseen in these proposals.

PUBLIC KEY SUPPORT

A vendor consortium focusing on distributed security called SESAME --
which includes Bull, ICL, and Siemens-Nixdorf -- has proposed a number
of extensions in DCE-RFC 19.  These extensions would begin the
integration of public key support in DCE.  Public key (or asymmetric
key) protocols are valuable when providing secure offline electronic
document interchange and long-term digital signature and notarization
services.  Inclusion of these protocols in the DCE will provide a common
framework for supporting these services and in certain cases will aid
cryptographic key distribution.  In addition this proposal provides a
mechanism for supporting multiple encryption algorithms in DCE.

SECURITY MANAGEMENT

Simplifying administration is a critical concern for the DCE community
in general, and centralized management facilities are a crucial element
of HP's strategy for managing DCE and non-DCE environments in
particular.  Work in this area therefore involves, first, simplifying
the administration of existing and planned individual security
facilities.  For example, OSF's DME project has begun to examine
strategies for sharing access control lists (ACLs) among many objects.
Roles have also been considered as a means to segment and simplify the
administration of these objects.  A role model is proposed in DCE-RFC
19.

The next step is to develop a common centralized management framework
within which individual security facilities can be integrated.  In this
area HP is investigating the utilization of its OpenView network and
system management framework to manage DCE security services as well as
DCE-independent security applications and general administration tasks.
OSF's DME, which is based heavily on HP's OpenView technology,
represents HP's distributed security management long-term direction.

OpenView and its DME descendent are ideal technologies for integrating
individual security facilities into a common security management
framework due to their object-orientation.  The characteristics of
object manipulation (e.g., inheritance, containment, association)
naturally facilitate the integration of security administration
attributes.  HP is actively prototyping OpenView based security
administration tools to demonstrate these concepts.  Productization
plans will follow.

4.2.4  Security Aspects Not Addressed by DCE

Some important security services remain outside the definition of DCE.
These service areas are by no means less important than the areas where
DCE is currently evolving, but they present difficulties for inclusion
in an open software environment, or are being defined and developed in
other fora.  Examples include non-repudiation facilities, long term
digital signature, notary services, and trusted X protocols.

Non-repudiation facilities, long-term digital signature, and notary
services protect against users denying having sent or received an
electronic message.  These services are of particular interest to
financial services providers that need to protect the integrity of
financial transactions against fraud.  However, these services are
examples of technology that is constrained in use due to licensing
issues.

Trusted X protocols are required to protect user interfaces based on the
X-window system from a threat which they are currently vulnerable to
called spoofing.  A trusted path for X environments is required to
ensure that users have a direct and distinct communication path to the
DCE authentication system.  It prevents malicious attempts to capture a
users password through the use of programs or physical system interfaces
designed to trick or spoof users into supplying passwords at fake
prompts for authentication secrets (e.g., passwords at logon prompts,
PIN numbers at ATM prompts).  Trusted X protocols are being pursued by
both the X Consortium and the Trusted System Interoperability Group
(TSIG) which HP co-founded and also are being examined by the OSF
Security SIG.

4.2.5  Role of Local System Support within DCE Domains

DCE provides a framework for deploying distributed applications. The
success of the environment is not only dependent on the distributed
security services of DCE, but also on the integration and support of
local system security features.  DCE provides a logically centralized
repository for system security information, but it does not obviate the
need for local security features.  Adequate local system security is
crucial to the viability of the DCE environment.  Moreover, the design
of DCE allows the interconnection of machines with varying strength of
local security.  Vital data repositories and application servers should
run on machines that provide strong local operating system and physical
security.

Besides strong local operating system security features, other local
system features which can complement the level of security provided by
DCE include smart card integration which can relax the level of trust
required in client machines to safely store sensitive information such
passwords and encryption keys; system management tools to protect
against trojan horses or viruses in local file system nodes; and
hardware to increase the performance of data integrity checks and data
encryption of DCE applications.  Because all of these facilities can
complement the level of security in non-DCE environments as well, these
facilities are discussed in more detail in section 4.3 which addresses
DCE-independent methods to enhance computing environment security. HP's
strategies and activities in these areas are also described.

4.2.6  DCE Security Policy Directions

The primary goal of DCE is to enable the development and deployment of
distributed applications.  Generally, the DCE security component avoids
implementing policy constraints; it simply makes the definition of
policy possible.  It is, however, helpful to extend the DCE facilities
to simplify the construction of applications applying security policies.
Common policy facilities sought after in the commercial environment
include separation of duty facilities; shared ACL repository and access
validation server; and additional environmental considerations such as
access control to objects based on variables such as location of request
and time-of-day.

4.3  DCE-Independent Methods to Enhance Computing Environment Security

Prior to the proliferation of DCE systems, millions of non-DCE systems,
applications, and security schemes will have been deployed as
illustrated in the security model graphic found at the introduction of
Section 4.  In most cases the security of these legacy approaches is
much less than desired for future open distributed computing
environments.  Although stronger security is available in DCE, most
existing applications will not be revamped to take direct advantage of
DCE's security services.  This section discusses some of the
DCE-independent methods available from HP or third-party partners to
enhance the security of existing environments and without modifying
existing applications.  They include utilizing enhanced security
operating system mechanisms, application support services, system
management facilities, trusted hardware components, and networking
elements.  Other methods are described that can be applied to the task
of enhancing the security of new non-DCE applications, as opposed to
existing non-DCE applications.  They include implementing alternative
(i.e., non-DCE) APIs for security services.

4.3.1  Enhanced Security Operating System Mechanisms

Enhanced computing environment security can be achieved through
operating system level features which may be implemented on DCE or
non-DCE nodes.  In the case of DCE nodes, this functionality may enforce
a local system policy which complements the level of security provided
by DCE, as eluded to in section 4.2.5 above.  Alternatively, this
functionality may be obviated by corresponding functionality available
or planned for DCE as stated earlier in section 4.2.6.  For non-DCE
nodes, however, this type of security represents the traditional data
center approach to providing security in a typical standalone
host-terminal configuration.  Because HP will continue to sell systems
into these environments, HP' strategy includes a parallel investment in
operating system level facilities for securing the individual
stand-alone node regardless of whether or not that node is slated for
integration within a DCE environment.

HP has already enhanced the security level of its HP-UX operating system
with features that are designed to exceed the U.S. Department of Defense
National Computer Security Center (NCSC) Orange Book criteria for a C2
rating.  These enhancements include an auditing sub-system which
improves user accountability by logging all security relevant system
events; access control lists (ACLs) which provides increased flexibility
in authorizing or restricting file access at the granularity of an
individual user; and a protected password database to thwart password
guessing attacks.  HP has similarly enhanced the level of security in
the MPE/ix operating system and is in the process of evaluation with the
NCSC targeting a C2 rating.

Future HP-UX operating system level enhancements are in the areas of
Password Management, Logon Restrictions, and System Administrator Roles.
HP plans to deliver the password management and logon restriction
functionality in the next major release of its HP-UX operating system.
System administrator roles will be offered just as soon as the POSIX
standard for least privilege crystallizes.  In fact, HP has implemented
a super-set of these features in an enhanced security version of HP-UX
called HP-UX BLS (B-Level Security).

HP-UX BLS addresses the more complex multi-level security needs typical
in federal government and defense-related communities which process
sensitive information and is in the final (Formal) phase of evaluation
by the NCSC targeting a B1 rating.  HP's strategy is to leverage its
investment in security features already implemented in the HP-UX BLS
release stream that are of interest to HP's mainstream commercial
accounts -- such as HP-UX BLS password management and logon restrictions
-- by migrating these features to HP-UX over time.

PASSWORD MANAGEMENT

Commercial customers realize that user authentication achieved through a
robust password management mechanism is the first line of defense
against unauthorized system and data access.  Password management
mechanisms have been specified by a number of emerging commercial
security criteria as a minimum requirement for commercial password
management sub-systems (e.g., NIST Minimum Security Functionality
Requirements for Multi-User Operating System (MSFR)). They include
password generation functions which provide a random pronounceable
system generated password option to ensure that all users use effective
passwords; password screening which checks user selected passwords
against a number of password criteria for complexity and guessability;
and password aging mechanisms for setting minimum/maximum password
lifetimes.

LOGON RESTRICTIONS

Logon restrictions or system-level access controls provide commercial
customers with the increased flexibility they require to control system
access based on attributes such as time-of-day or terminal ID rather
than simply User ID.  In addition, administrators need the capability to
automatically and temporarily disable terminal IDs and/or user accounts
based on logon attempts threshold, password or account lifetime expiry,
or account inactivity (i.e., dormant accounts). Logon restrictions have
also been specified by a number of emerging commercial security criteria
as a minimum requirement for commercial system level access controls.

SYSTEM ADMINISTRATION ROLES

System administration roles enforce the age-old security precept of
separation of duty in order to limit the degree of system control
entrusted to any individual.  Examples of roles include system manager,
security administrator, system operator, etc.  In a Unix environment
this implies eliminating the need for the monolithic and all-powerful
super-user privilege and replacing it with more narrowly defined sets of
privileges.  Super-user privilege is especially dangerous in Unix
environments because direct logons are  not uniquely identified, and as
a result accountability for actions is lost.  A least privilege model,
which supports the principle that each subject should be given no more
privilege than absolutely required to perform its intended function,
represents the preferred approach to implementing system roles
effectively.  A least privilege model for open systems is not practical
today due to the immaturity of the emerging standard for privilege
definition.  Nevertheless, secure administrator interfaces (e.g., menus,
restricted shells) which limit administrators to predefined tasks can be
utilized today.  However, this approach does not provide the same level
of assurance as a least privilege model.

4.3.2  Application Support Services

Application support services can be implemented above the operating
system level to enhance the security of non-DCE domains which host
distributed applications.  Non-DCE distributed-applications tend to use
conventional networking services provided by communication software
libraries (e.g., TCP/IP, SNA, SPX/IPX, or X.400 messaging).  Enhancing
the default security of these services is one way of bringing
applications into a more secure distributed environment without
modifying the applications which use them.  For example, it is possible
to force TCP/IP connections to be encrypted providing near end-to-end
privacy.  This approach may be attempted with any runtime libraries that
support existing applications.  HP's strategy is to follow the
recommendations of the Internet Engineering Task Force (IETF) for
enhancing the security capabilities of both TCP/IP and the Simple
Network Management Protocol (SNMP II) which is built upon TCP/IP.

Legacy applications may use a variety of other application support
services.  They may be based on vendor supplied de facto standards or
custom built ad hoc solutions.  Also, they may be operating system or
environment based (e.g., database security features like Views, Novell
network logon).  On an individual basis, interfaces may be designed to
integrate these methods into a more standard security facility (e.g.,
X.509) or even into remote DCE security services.

In some cases vendors will be evolving these interfaces from their
proprietary approach to a more standard security methodology.  For
example, leading relational database vendors are delivering secure
database engines which utilize the security facilities of selected
standards-based secure operating systems.  Both Oracle  and Informix
have selected HP's trusted (B-Level) secure Unix-based operating system,
HP-UX BLS, as the reference platform to base National Computer Security
Center evaluations of their B1-Level secure database offerings.

4.3.3  System Management Facilities

Another approach to improving general computing environment security is
to implement system management facilities which either provide a
security assessment function or integrated system management facilities
which encompass security audit and control as well most general system
administration tasks.

SECURITY ASSESSMENT TOOLS

These tools can offer consolidated network security assessment, risk
analysis, security policy or baseline exception-condition reporting,
monitoring, and automatic correction facilities thereby dramatically
reducing the time and expertise required to maintain and improve
security in distributed environments.  These security assessment
software products generally focus heavily on file system attributes
which if not set securely can leave the system vulnerable to a number of
threats including unauthorized use, viruses, and trojan horse attacks.
Security assessment software can also include error log analysis,
configuration guidelines, password administration, process inventory,
and networking profiles.  This software can be run on demand or
continuously depending on performance and administration overhead
sensitivity.

HP's strategy is to ensure that the leading independent software vendor
products that perform these functions are available on HP hardware
platforms.  Examples of such products which HP-UX currently supports
include the Security Toolkit from Raxco Systems and SecureMax from Demax
Software.

INTEGRATED SYSTEM MANAGEMENT TOOLS

Some system management add-on products are much more ambitious with
regard to the scope of security and system management facilities they
offer than the security assessment software products just described.
They include IBM's Resource Access Control Facility  (RACF) and Computer
Associates Top Secret  and ACF2  for data center environments and
CA-Unicenter  which has been ported to the HP-UX platform.  For example,
CA-Unicenter for HP-UX supplants most of the security controls built
into HP-UX such as the logon sub-system, file system access controls,
and auditing sub-system as well as most other general system management
facilities such as performance, storage, production, as well as security
audit and control management.

Computer Associates is in the process of evolving this management
architecture to support distributed, multi-vendor environments.  HP's
strategy is to offer this approach to customers that wish to down-size
from larger IBM mainframe systems while retaining familiar system
management concepts and interfaces.  For customers willing to
re-engineer their global computing architecture, HP provides the
flexibility and scalability of DCE.

The graphic below illustrates how the traditional system security model
for HP-UX (right-middle portion of graphic) compares with the mainframe,
data center approach as exemplified by the CA-Unicenter product for
HP-UX (far-right portion of graphic).  Note, the traditional system
security model for HP-UX consists of built-in operating system level
security features (as described in Section 4.3.1), a system
administration environment, and add-on security assessment tools.  This
contrasts with the CA-Unicenter architecture which spans all three
security layers depicted in the model.

4.3.4  Networking Elements

While the previous sections focused on efforts to improve security via
on-host mechanisms, this section addresses off-host approaches based on
the communication components (e.g., bridges, multiplexors, modems,
routers) that comprise the network.  Enhancing the security of these
elements or adding link security devices (e.g., link encryption devices)
can usually be accomplished transparently with respect to existing
applications.  Furthermore, these methods generally can continue to be
used even with the introduction of higher level security methods such as
end-to-end encryption (ETE).  If all applications were using ETE
encryption link encryption of course would be redundant.  However, in
cases where existing applications and systems cannot be enhanced with
ETE or near-ETE encryption, link encryption would certainly improve
confidentiality of these applications.  HP supports third-party link
encryption devices which provide this level of service.  It is generally
recognized, however, that ETE encryption is clearly the best solution
whenever achievable.

There are many other security enhancements that can be added at the link
level besides encryption.  For example, bridge filter tables can be used
to segregate network traffic by source or destination address.  Routers
can filter traffic based on message type, and higher level addressing
such as the Internet or Novell network address protocol (XPI).  Once
again these methods generally do not interfere with the introduction of
security methods such as ETE encryption.  HP is adding these type of
security services as well as link encryption capabilities to its bridge
and router product lines.  In addition, modems are available from
third-parties with dial-back, password, or encryption capabilities, to
strengthen remote sign-on user authentication.

A significant disadvantage of using network elements to enhance the
security of a distributed application lies in the area of
administration.  The simple task of adding a new PC or workstation to a
work group illustrates this point.  The administrator must perform all
of the normal account setup activities on relevant servers and clients.
Often this has been automated because of the repetitive nature of the
task.  However, if the bridge filtering technique had been deployed as
described above, then the administrator must include the ethernet
address of the new PC or workstation in the bridge filter table or else
the new node will not be able to communicate with the servers.  Thus,
required knowledge of ethernet addresses and network topologies
complicate otherwise routine account set up tasks.  HP's DCE provides a
centralized management framework for distributed security which may
obviate the need for network security elements.

4.3.5  Trusted Hardware Components

Security of both DCE and non-DCE systems can be enhanced by means of
trusted hardware components.  Encryption hardware and smart cards are
two examples of this type of component.  HP is actively developing
encryption hardware which is integrated with and complementary to its
smart card support plans.

Encryption hardware provides a highly trusted facility in which keys can
be stored and in which highly optimized encryption and decryption
services can be performed.  The software and/or hardware that carry out
these services can be trusted to protect against unauthorized
modification or trojan horse attacks.  This level of trusted key storage
and performance is required to successfully support digital signature,
message authentication, and data encryption activities in untrusted
systems.

Smart cards provide a low cost but trusted facility that can be used to
strengthen weak parts of the authentication process such as user
selected passwords.  They can also be used to assist in the digital
signature process.  Their tamper resistant features together with their
nature as personal device make them a socially acceptable security
enhancement for the mobile user community.  While today's smart cards
tend to be single purpose cards there is a good deal of interest in
developments that make use of multi-purpose smart cards which could
support system-usage accounting and chargeback controls, software
license controls, as well as security access controls.

4.3.6  Alternative APIs for Security Services

The previous sections focusing on non-DCE environment security
emphasized methods to avoid modification of existing applications.  This
section examines non-DCE facilities that are useful to application
developers who choose to include certain security features in their
applications.  First, there are APIs available for accessing general
security services (e.g., GSS, CCS, TSS).  These APIs are available in
packages from some vendors today.  HP is driving for the emergence of a
standard API and will implement this API in its product offerings.

Second, there are some product specific APIs available for accessing
specific security features.  For example, widely adopted products can
establish defacto standard APIs for particular security services (e.g.,
Kerberos authentication services, RSA encryption services).  The range
of products available in this area is growing quickly.  They are often
attractive to organizations that have identified one or two key security
threats. However, an administration and interoperability problem becomes
apparent as more and more threats are identified and more security
products are integrated.  Since there is no standardization effort in
this area, interoperability of these various security solutions is very
much a custom process.

HP recommends that before following this path, it is wise to select an
umbrella security architecture standard (e.g., X.509, DCE, RACF) into
which independent solutions can be integrated.

4.3.7 Alternative Security Architecture Standards

The Directory based authentication framework (X.509, ISO9594-8) is an
example of a standard that can be used to support an enterprise security
architecture.  Since the directory holds information that is needed for
communication protocols and is accessed prior to communicating, it is a
natural place to store, distribute, and maintain authentication
information.  X.509 describes some specific attributes necessary to
support simple and strong authentication, however, this is an extensible
facility and other security attributes can be defined.  The most
significant attribute specified in X.509 is the user's certificate -- a
collection of information about a user that is produced by a trusted
certification authority.

The certificate is important in that it provides an internationally
standardized means to disclose a user's public key.  As mentioned
previously, support for public key cryptography is fundamental to most
modern authentication schemes.  Both the certificate content and its use
are extensible to support a specific enterprise security policy without
impacting open systems interoperability.  Furthermore, the certification
authority necessary to create certificates requires adaption to the
enterprises specific corporate structure.

The viability of using X.509 to support enterprise security
architectures depends on the growth and availability of Directory
products.  Although X.509 can be considered as an umbrella enterprise
security architecture, HP's position is that the DCE architecture is a
more comprehensive solution for integrating alternative security
environments including X.509.

4.4  Network Planning

Planning for security enhancements is an important first step and can be
carried out even when budgets are tight and ideal solutions have not yet
matured.  The planning process should begin with a projection of
organizational requirements for IT.  In the 90's these requirements
generally reflect aggressive distributed computing services that offer
competitive performance and flexibility.  Security may or may not be
included in an organization's outlook for IT growth.  HP's position is
that security should be included in IT planning and offers consulting
services to assist with this activity.

If DCE is chosen as the future environment for an enterprise then the
DCE security framework can be used for network planning of security
services.  Even if the entire enterprise does not uniformly deploy DCE,
the DCE security framework can be used as the overarching security
architecture for the non-DCE components.  Network planning would then
include identification of interfaces between the non-DCE systems and the
DCE security services.  There will be environments where DCE services
will not be accessible or where a non-DCE security framework has been
chosen as the overarching architecture (e.g., X.509).  Network planning
in these cases will involve designing of the interfaces required to
integrate various security solutions into the chosen architecture.

Network planning for security should include an assessment of emerging
security related technologies and their impact on improving distributed
computing.  For example, smart cards can provide strengthened
authentication and support for digital signature even in very untrusted
systems like PCs.  In many commercial business sectors the cost of smart
card integration is being defrayed by the savings from reduction in
fraud and misuse.  Once again, planning is important in understanding
how smart cards would be introduced, used, and administered in any given
application environment.

Network planning also must consider solutions and activities which are
not technology driven such as security policy development; user
awareness, education, and training; physical security options; and
network configuration techniques.  For example, traditional network
configuration techniques such as firewalling can be used to protect a
trusted local area network while preserving a level of remote
communication.  Within the security perimeter of a LAN, users may
communicate freely.  But, all messages sent to or from users outside the
network must pass through a firewall or gateway computer, that checks,
routes, and labels information passing through it.  In sum, HP can bring
to bare the power of consulting and technological solutions to address
customer security needs.

5    Application of HP's Security Strategy:  Case Example

The previous sections of this white paper describe HP's security vision
and implementation strategy.  This section offers an example of how HP's
security vision and model can be used to meet a specific customer
requirement for a consolidated logon process.

CONSOLIDATED LOGON PROCESS

A consolidated logon process provides user authentication at a network
entry point.  Users engage in a single logon dialog with the network
security service.  Once users are authenticated, they may access a
variety of applications and servers without additional logon dialog.

The figure illustrates an approach to consolidated logon which utilizes
proposed extensions to the DCE user registry facility.  It provides a
mechanism to incorporate existing applications into the DCE environment.
This approach assumes that the network entry point system supports DCE.

As shown in the figure, the various proof mechanisms for all networked
systems are collected into a Security Registry.  The Security Registry
contains all the security relevant attributes of the various users.
These attributes may include information such as account identifiers
(user ids) and passwords for legacy systems and applications.  The
Security Registry is based on enhancements to DCE currently planned for
DCE 1.1 and described in OSF DCE SIG RFC 6.0 - A Generic Interface for
Extended Registry Attributes.  The current DCE 1.0 repository stores the
network privilege attributes used by DCE as well as local account
attributes usable by UNIX operating systems.  The enhancements planned
for DCE 1.1 provide a mechanism for storing user and group attributes
for arbitrary operating systems.  These attributes may be used to
implement a consolidated logon process.

Network access is controlled by a specialized logon client which is a
DCE application.  This logon client may run on any system which supports
DCE including PCs running PC-DCE from Gradient Technologies.  Users
access the logon client either directly via the workstation display or
attached terminal or indirectly from a non-DCE client via some trusted
protocol outside the scope of DCE.  The logon client processes the
security attributes received from the Security Registry.  These
attributes include standard DCE security attributes as well as user and
group attributes such as user ids and passwords for legacy operating
environments.  The logon client passes these security attributes to
various application and client processes via operating system specific
mechanisms.  Legacy applications can be supported in the consolidated
logon environment in a number of ways.  A variety of possibilities are
examined below in the order of increasing modification to the
application.  In all cases there is no need to change the application's
security model.

1. Local applications.  These applications run on the same system as
   the DCE logon client.  Security attributes are passed to them via
   standard operating system mechanisms.  No changes are made to
   the legacy application.

2. Existing Remote Legacy Applications.  These are applications
   which are already distributed and have their own protocol for
   transmitting authorization data.  For these applications, user
   account/password attributes are passed to the applications via some
   non-RPC network interface.  The attributes are used to provide
   operating system or application specific authentication and
   authorization, possibly using some scripting mechanism.  For
   example, HLLAPI may be used to pass logon information to an
   existing IBM application.  No changes need to be made to these
   applications.

3. Encapsulated Legacy Applications.  These are legacy
   applications which run on a system which supports DCE.  These
   applications are encapsulated in a DCE Wrapper which provides
   remote access to the application.  Extended security attributes for
   these applications are passed in a standard DCE PAC (Privilege
   Attribute Certificate).  The wrapper function processes the remote
   request and sets the local O.S. environment to reflect the legacy
   attributes.  The legacy application is then invoked by the DCE
   wrapper in the normal local manner.  No changes are made to the
   legacy application.

4. Client/Server Legacy Applications.  These are existing
   client/server applications which use some non- RPC communications
   mechanism such as LU 6.2 or Berkeley Sockets.  The GSS API
   described in OSF DCE SIG RFC 5.0 (if available on the legacy
   platform) may be used to add security features to these applications.

   The security features offered are analogous to those which DCE
   offers to RPC-based applications.  The legacy application retains its
   existing communications model but adds the use of GSSAPI to
   achieve secure transmission of authorization data and for the
   integrity or confidentiality protection of the communication.

5. Re-engineered DCE Applications.  These applications use
   standard DCE mechanisms for communication.  Remote interfaces
   are designed to use RPC.  Extended security attributes for these
   applications are passed in a standard DCE PAC (Privilege Attribute
   Certificate).